Firmware deployment and update workflow

This chapter describes a deployment workflow specific to STM32CubeIDE for Visual Studio Code.

It covers three areas included in this documentation set:

  • Build artifacts produced by the STM32 build flow

  • Programming during development through debug configurations

  • Repeatable release programming through project tasks

This chapter does not require a specific production programming utility. The programming command depends on the product process and hardware setup.

Use the correct build artifacts

The build chapter defines the primary artifacts used during STM32 development:

  • .elf for debug sessions and symbol-aware analysis

  • .hex and .bin for programming and update packaging

  • .map for memory review and release traceability

In STM32CubeIDE for Visual Studio Code, these files are produced by the active build configuration, typically Debug or Release.

For artifact definitions and output context, see Build.

Development programming in Visual Studio Code

For daily development, use the Run and Debug workflow described in the debug chapter.

Recommended sequence:

  1. Build successfully to generate the current .elf.

  2. Open Run and Debug and create launch.json if needed.

  3. Select the correct debug probe configuration, such as stlinkgdbtarget or jlinkgdbtarget.

  4. Start the debug launch and verify that the image and symbol path are

correct.

Practical guidance:

  • Maintain one debug configuration per target board

  • Use explicit names in launch.json for multi-target projects

  • Enable preBuild to ensure each debug session flashes the latest build output

For debug configuration details, see Debug.

Release programming with tasks

For release and manufacturing preparation, define programming steps as workspace tasks instead of manual terminal commands.

Why this approach is preferred in this environment:

  • The command is version-controlled in .vscode/tasks.json

  • Team members run the same command from the same workspace

  • Terminal output can be archived with the release record

Minimum task set for release preparation:

  1. Build the Release configuration.

  2. Program the target with the approved production command.

  3. Run a post-program verify step.

  4. Save command output as release evidence.

For task configuration patterns, see Build and Projects.

Release traceability

Each release candidate should include a small manifest that links the image to its source and tool context.

Recommended manifest fields:

  • Product identifier

  • Firmware version

  • Source revision

  • Artifact names for .elf, .hex, and .bin

  • Checksum or hash values used by the process

If the team uses bundle pinning, also record the bundle baseline used to build the release. The command-line toolbox chapter describes bundle-oriented project setup and installation.

For CLI context, see API manual.

Update architecture choices

STM32CubeIDE for Visual Studio Code supports different firmware update architectures. The IDE does not require a specific model.

Common models:

  • A/B image slots with controlled switchover

  • Single application slot with a recovery loader

Selection criteria:

  • Available flash and non-volatile memory budget

  • Recovery requirements after an interrupted update

  • Bootloader capabilities in the product

Define update-state flags, integrity checks, and rollback rules in the product specification before implementation.

Validation before rollout

Before release approval, verify at least the following on target hardware:

  1. Programmed artifact matches the expected release artifact.

  2. Reported firmware version matches the release manifest.

  3. Device boots cleanly after a power cycle and reset.

  4. Critical peripherals initialize and run as expected.

  5. Watchdog and fault-recovery behavior are validated.

Recommended evidence to archive:

  • Build log for the released artifacts

  • Programming and verify logs

  • Test verdict summary

Typical failures and recovery

Use predefined recovery steps for the most common deployment failures.

  • Image mismatch after programming

    • Stop deployment for that target

    • Re-run the program and verify sequence

    • Keep logs for root-cause analysis

  • Boot failure after update

    • Recover using the product rollback path

    • Capture failure context from debug tools

    • Re-test with the last known-good image

  • Functional regression on the updated image

    • Pause rollout

    • Reproduce with the exact release artifact set

    • Resume rollout only after corrective validation